IBIS Macromodel Task Group

Meeting date: 18 August 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                              Curtis Clark
Avago (LSI)                   Xingdong Dai
                              Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC                         David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
IBM                           Steve Parker
Intel:                        Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                              Nicholas Tzou
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                            * Todd Westerhoff
                              Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:               Bob Ross
TI:                           Alfred Chong

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- None.
--------------------------
Call for patent disclosure:

- None
-------------
Review of ARs:

- None
-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Todd: They look fabulous.
- Todd: Motion to approve.
- Arpad: Second.
- No objections.

-------------
New Discussion:

Info, Out, InOut BIRD draft:
- Arpad: Last week we had a discussion on Info, Out and InOut, discussing how 
      to tighten up the spec on it.
    We could have a new branch, so if a parameter ends up in the spec it won't 
	  lead to parsing issues.  
    We could have a sub-branch under Model Specific but agreed it wouldn't be a
	  good idea so the DLL wouldn't need to be rewritten if the parameter 
	  becomes standardized.  
    I would like to make a decision today on what the rules should be.
- Todd: What problem are we trying to solve?
- Arpad: His understanding is that one of the main strengths of IBIS is 
      portability.  
    If we have Model Specific parameters with these usages, a model could 
	  become non-portable and IBIS will become less usable in the end.  
- Todd: So, the problem is that parameters that get put in the model affect 
      how the model interacts with the simulator, and these are not part of the
	  existing definitions of parameters.  
    Are we trying to prevent it from happening, acknowledge it happens and 
	  standardize it?  What is the goal?
- Arpad: The goal is preventing EDA vendors from hearing complaints about 
      models not working in all tools.  
    We need to make it clear that certain features are for certain tools.
- Todd: It is a delicate topic of standardizing the non-standard.  So, it seems
      we are saying that if you work outside the standard, then you should 
	  identify it clearly with this mechanism.  
    We are acknowledging that this happens.
- Arpad: If we make a model that works in only one tool, is it an IBIS model, 
      since it doesn't follow the spec?
- Todd: So are we going to say that these models are ok?
- Arpad: The spec does allow now models that will be proprietary, due to a 
      loophole.  This is mostly AMI-specific.
- Ambrish: Why hide behind the spec and pass something that will for sure not 
      work in other tools?  
    Why not use comment characters so the parser doesn't choke?  
	We have used this before and it has worked.
- Walter: How can any Out or InOut parameter cause any tool to have problems?
- Ambrish: You are hiding behind the Out parameter to see different results in
      different tools.  
- Walter: What if a manual that came with the model reports what an Out 
      parameter does and issues warnings?  
    If the model maker documents what the Out parameter does, and an EDA tool 
	  chooses to read that parameter or the user does, why should we prevent 
	  that from happening?
- John: The Model Specific branch is for this type of information already.
- Todd: Arpad is right in saying there is a loophole.  Results can be affected
      by these Out parameters.
- John: Model Specific parameters can affect the output by allowing the user 
      to change certain settings.  
    But there can be tool-specific implementations.
- Ambrish: We could prevent Model Specific parameters from being Info so that 
      they are only used by the tools.
- Todd: So we are trying to address model portability between tools.  
    Are we trying to tell EDA vendors their simulator shouldn't recognize 
	  specific parameters and do special things?  
    Or are we just trying to let people know this is happening in a standard way?
- Arpad: We can allow this, but we shouldn't lead users into thinking the model
      is completely IBIS compliant and will work in all tools.
- Todd: Users don't always understand nuances of the standard, don't want to, 
      and don't want to get into details when they just want to get their 
	  work done.  
    He has spent a lot of time telling customers why certain models don't work.  
    He learned to find ways of just getting models to work.  
    Support for Touchstone files is an example.  
    You'll get the same result just dropping the S-parameter in the schematic.
- Walter: You won't get the same result.  
    The model says to use a specific Touchstone file.  
    But the user gets things confused half the time and sets it up wrong.  
    Model makers don't want this source of error.  
    They just want it linked in the AMI file.  
    SiSoft did something proprietary to fix the issue.
- Todd: There are cases when tools are innovating, and hopefully they are at 
      least telling people what they are doing.  
    There is a point when this solution gets brought to IBIS.  
    If it isn't accepted, then at some point models need to be rewritten to 
	  support a standard way.
- Ambrish: When does the reconciliation process happen?  
    How should we prevent proprietary methods from continuing to be used and 
      not get updated to use standard methods?  
    How can we move Model Specific parameters back into the spec?
- Radek: There have been discussions that all the simulators don't know what 
      to do with the Model Specific parameters.
- Arpad: What if we suggest that Model Specific parameters can only have In types.  
    The parser could allow Out but flag it with a message.
- Todd: There are good uses for Out types.
- Ambrish: Can we say that Info is not allowed?  
    That type is meant for the tool only.
- Todd: That is stifling innovation.
- Ambrish: The parser could issue a warning.
- Radek: In that case the simulation should error out if the parser fails.
- Todd: There are three parts to this.  
    Can we advance the standard and allow model portability with information 
	  sharing? 
    There is then a responsibility to bring new ideas to the standard.  
    Then There is a time when models have to be brought into compliance.
- Ambrish: What can you do when a parameter notifies you that a model may work
      differently in different tools?
- Todd: It could be put in Reserved Parameters and cause a parser issue.  
    One thing is that we could use the notification method of comments such as 
      "|SiSoft". 
    The burden is not legislation but notification. 
    Or we can come up with a new method.
- Ambrish: The parser does the job of notifying you of potential issues.
- Walter: It seems best to use the comment field when there is an advanced 
      feature.
- Ambrish: This means you can't legislate any way of controlling this.  
    But it is a good way of notification.
- Walter: In reference to Radek's comments, making Model Specific parameters 
      that are Out was not a loophole.  
    It was specifically intended to do these kinds of things.  
    That was the mechanism for experimenting with new things that could go 
	  into the standard.  This was not a loophole.
- Ambrish: Is there any issue with a parser warning that parameters in Model 
      Specific may cause differences in different tools?
- Todd: Maybe we should make a legitimate place for these parameters.  
    If we just take Info type Model Specific parameters and flag them, there 
	  are workarounds like making them In type so they don't generate parser 
	  messages.  
    Generating parser messages does create a tone of models being bad.  
    It would be better to legitimize the model innovations.
- Walter: Motioned to table the unofficial BIRD and continue with the way 
      things are handled now.  
    No second.
- Arpad: Coming back to how to make this legitimate, John said there was an 
      issue with my previous suggestion, but I would like to understand better.  
    Can't we have a way to pass proprietary parameters by inventing new 
	  Usage types, such as InfoProrietary, OutProprietary, InOutProprietary 
	  and use these for the non-standard, innovative parameters?

- John: InOut does the legitimate thing and Info does the proprietary thing.
- Radek: When you put something into the Model Specific section, you don't 
      pass the branch name into the DLL. 
    We are asking for a better established way of informing the user.  
    We have a description string in the definition of the parameters.  
    That could be used to inform the user.  
- Arpad: The parser can't flag that.
- Radek: The parser could flag a Model Specific section with Info or InOut, 
      noting that the model could be proprietary.
- John: Jitter parameters in the Model Specific branch could be Out.  
    There is a hole for notification.
- Arpad: I think we should continue thinking about a solution to this.
- Todd: There has been better agreement on the notification aspect of this.  
    We want the user to easily see that a model may only work in specific 
	  tools.

-------------
Next meeting: 25 August 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
